The present embodiments relate to computer networks and are more particularly directed to a scalable virtual local area network (“VLAN”) grouping in a provider Metro Ethernet.
Ethernet networks have found favor in many applications in the networking industry for various reasons. For example, Ethernet is a widely used and cost effective medium, with numerous interfaces and speed capability up to the Gbps range. Ethernet networks may be used to form a network sometimes referred to as a Metro Ethernet Network (“MEN”), which is generally a publicly accessible network that is often affiliated with a metropolitan area—hence, the term “Metro” Ethernet. A MEN provides a so-called Metro domain, typically under the control of a single administrator or manager, such as an Internet Service Provider (“ISP”). A MEN is typically used to connect between an access network and a core network. The access network often includes edge nodes that couple to private or end users, that is, customer nodes, making connectivity to the network. The core network is used to connect to other Metro Ethernet Networks and it provides primarily a packet switching function.
With the development of the MEN architecture, there have further evolved additional topologies associated with such a network. One type of such an overlay is referred to as virtual local area network (“VLAN”). Previously a LAN was considered a network spanning a short distance, such as within a single building or campus and for a single company. However, with the MEN architecture, an entity such as a business can obtain interconnection at greater distances and through the MEN, thereby giving rise to the VLAN in that from the perspective of the entity, users within it still have access in a manner that appears for practical purposes no different than a LAN, but it is considered “virtual” in that it spans a greater distance to remote locations and overlays a bigger network. In addition, under the control of the ISP or other manager, a MEN is often used by multiple entities, or “customers,” whereby from one customer's perspective all other customers' VLANs are transparent. However, certain policies and issues are enforced by the manager because the different VLANs do in some instances share resources and, thus, a level of consideration of the interaction between supporting different customers across the same resources must be contemplated.
One aspect in support of multiple and different customers as well as within a customer on a MEN arises in connection with so-called Q-tags, which receive their name in that they are part of the IEEE 802.1Q standard and which are sometimes also known as VLAN tags. A Q-tag is a field that is included in each packet that is communicated in the MEN at the provider level so as to route the packet and thereafter also removed from the packet prior to the packet being routed ultimately to a customer node. For purposes of background to the preferred embodiments described later, two such Q-tags are of interest. A first Q-tag is used by a VLAN customer to subdivide its customer VLAN, sometimes referred to as a C-VLAN, such as by group within the customer. In other words, this first Q-tag identifies different groups within the C-VLAN of the respective customer. For example, if a customer has different business groups, it may assign a different Q-tag to each respective group, and network packets on its C-VLAN with a same Q-tag may then be treated in a manner consistent with the specific group corresponding to that Q-tag. Additionally, because this tag is inserted and used by the customer, it is sometimes referred to as a customer Q-tag. More recently, however, a so-called Q-in-Q scheme has been proposed under the still-developing IEEE 802.1ad standard. This scheme gets its name from the fact that it proposes adding a second Q-tag in each packet and, hence, this second Q-tag is essentially embedded in the same packet with the 802.1 Q-tag. This second Q-tag is inserted in the packets by a provider edge node that is controlled by the MEN manger (e.g., ISP) and to identify a customer. In other words, in general for a MEN with different C-VLANs, then each C-VLAN has a corresponding different Q-tag of this sort. Further, since this second type of Q-tag is inserted by the provider edge node, then it is sometimes referred to as a provider Q-tag.
While the preceding use of Q-tags has proven useful in various operations of a MEN, a drawback has arisen with the increased number of C-VLANs per MEN. Particularly, the provider Q-tag has been understood to use the same general format as the customer Q-tag, particularly given the embedded nature of the Q-in-Q scheme. Thus, since the customer Q-tag is limited to 12 bits, then so has been the provider Q-tag. Moreover, while 12 bits typically provide 4,096 different identifiers (i.e., 212=4,096), some of those identifiers are reserved and, hence, in actuality only about 4,000 identifiers are available for the customer Q-tag. Similarly, therefore, only about 4,000 identifiers are available for the provider Q-tag. While this number may appear sufficient in some contexts, in contemporary MENs an increasing number of C-VLANs may require support in a single Metro domain and, hence, once that number exceeds 4,000, then each C-VLAN may no longer be separately identified by a respective provider Q-tag. Therefore, there is a potential scalability problem that needs to be addressed.
One solution has been proposed in an effort to address the above-introduced drawback of increased number of C-VLANs with the corresponding limitation of provider Q-tags in a single MEN. Specifically, an e-mail comment to the proposed IEEE 802.1ad standard suggests allowing different C-VLANs to have the same provider Q-tag, only where those different C-VLANs are all connected to an identical set of edge nodes. For example, for a MEN having edge nodes EN0 through ENy, and for two different customers Customer A and Customer B, both having customer nodes connected to the same set of edge nodes EN0 through ENy, then a single C-VLAN is used to identify Customer A and Customer B. As a result, traffic that is broadcast along this single C-VLAN will be received by the edge nodes that are connected to both Customer A and Customer B and, hence, that traffic may then be filtered if needed by the edge nodes or otherwise forwarded to one or both of those customers. While this approach therefore reduces the number of C-VLAN identifiers needed to indicate all of the C-VLANs on a MEN, it is also constrained in that there may be a limited number of customers that are connected to the very same set of edge nodes. Thus, this approach also has limitations and may not properly scale to a situation having a large number of C-VLANs.
Given the various nodes, attributes, and connectivity described above and known in the art, a need has arisen to address the system limitations, as is achieved by the preferred embodiments as further detailed below.